Module 12 Closure
Spring 2006
Prepared by Greg Kinney

Most meaningful items

• The most meaningful in this module was to learn about the purposes of control and the information needed for the different control systems to be able to work properly.

• Cybernetics, it wasn’t the most meaningful, however it the most familiar. Cybernetics is a different term for something I have already learned and know from Electrical Engineering (Auto-Control, Signal Conditioning, etc). The module showed how the concepts gain from these classes can be used in other types of systems (Non-electrical and Non-mechanical).  Instructor replies: If you are interested in it, I would recommend that you take a systems dynamics class at some point, or at least a computer simulation class, where you’ll see lots of applications that apply control theory tools to business problems, environmental problems, etc. 

• The complete chapter was excellent. The introduction to the basic control systems was educational because in the industry I work in they use projects methods up to about this point and then falter and use questionable methods. Then the PM is forced to spend all winter trying to put a final report together from dailies. The interface between administration and the PM on the project end of the work looks like it’s going to be the key.

• The clearest and most helpful part of this module was the identification and definition of the three types of control systems found in project management.  Cybernetic control is most familiar to me because I work with instrument panels that consist of controller, transmitters and sensing devices.  It was easy for me to understand the function and design of a cybernetic control system when it comes to feedback and set-point designations.  The go/no-go system was also slightly familiar to me from a manufacturing standpoint.  Now I know that the go/no-go system is the most common in a project management setting.  The post-control system was also familiar to me from my days on the slope.  I guess I never understood that each of these encounters I had would manifest itself in a project management course.  The text did an excellent job of distinguishing between the three types of control systems.  I have a better appreciation for the simplistic yet applicable nature of each type of control system.  Instructor’s reply:  See comment under “muddiest items” dealing with the issue of cybernetics falsely equated with automatic operation.

• This chapter focuses on the importance of project control systems to achieve objectives of time, quality, budget, scope and owner satisfaction. Controls must be well balanced, timely and flexible in order to be effective. Go/no-go controls are most widely used by project managers and include but are not limited to familiar tools such as activity and budget progress reports, quality checks, and testing. These may be triggered by milestones or periodically accomplished to monitor progress. Postcontrol is an effective tool in since lessons learned can be used to improve decisions in the management of future projects.

• Again, I liked to flesh out the processes I am already using.  Although I wonder about the postcontrol.  I think it’s a stretch to call after action reports as ‘control’.  That’s just me, I get stuck on funny things.  Now I have a much clearer idea of why my supervisors ask for some funny things.           

• Comment:  Overall, this module wasn’t really unclear in terms of content and presentation.  The muddiest or least clear part of this module had to do with problem 4 at the end of the chapter.  I didn’t understand how to formulate the critical ratio because I thought the question wanted the “formal” critical ratio defined on pages 561 and 562.  Other than that, I thought the module was extremely clear and made a lot of sense. 

• Comment:  What I missed a little bit in this chapter was the disadvantages/concerns about control systems. Some people in an organization are normally not too positive about control systems, how should they be motivated/convinced?

Instructor’s reply:  This is an excellent question that gets into organizational psychology.  People in general resist being policed, and project control systems can look a little like policing at times.  Everywhere I’ve worked, people have really hated timesheets – especially engineers.  And the way some of these kinds of control systems work, you can’t help hating it – particularly if you’re getting browbeaten about too many overhead hours.  

In the larger scheme of things, though, I’ve found that most people understand and accept the fact that project managers have to have good and relatively current information about their project status and trending.  If they don’t, then success at meeting the so-called “triple constraint” becomes improbable and purely accidental.  In my experience, just about anyone (assuming that they are basically rational to begin with) is likely to be convinced pretty easily about the need for control once the real stakes and the real alternatives (i.e., what will really happen without control) are laid out for them to see.

Under some circumstances, though, you’ll find that voluntary cooperation is another matter.  When it appears that the project control system may unveil poor performance, you can sometimes find unethical and unprofessional behavior including hiding information, constructing blame games, etc. 

• Comment:  The author did not seem to go into it, but wouldn’t a control system that uses cybernetics and Go/No-Go control systems during the various aspects of the project and post-control after the project be a logical control system to employ on a project? To me this would seem the most sensible and logical approach to controlling a project’s systems.

Instructor’s reply:  You’ve given me a great opportunity to go on a soapbox.  I have long been excited about systems dynamics, which in some applications is synonymous with cybernetics.  Systems have interacting elements that act probabilistically.  Inputs, processes, outputs and feedback are all essential elements.  Project systems are a case in point, and project controls should opportunistically exploit those elements of feedback that provide the most leveraging amount of information to influence outcomes. 

But these aren’t “automatic” processes.  The authors state that the “key feature of cybernetic control is its automatic operation.”  Human systems aren’t automatic, even though they can be usefully modeled as performing “automatic” control actions within probabilistic ranges.  As you know from your first semester controls course, you can draw a simple block diagram illustrating the automatic operation of a thermostatically controlled heating system.  You also know that the same block diagram applies to the manual operation of that system (i.e., when you open or close your hot water zone valve, adjust mixing box louvers, etc.): it’s just that the human operator is the sensing element rather than the thermostat.  It is no less a cybernetic system when humans do it than when it’s automatic.  I’m sure the authors know that, in project management, you have human systems in place and not remote sensors; unfortunately, their description didn’t quite make that clear.

In my opinion, an effective project controls system should include elements of both cybernetic and go/no-go controls.  The go/no-go process provides valuable feedback during the formative phases of the project, and (if done correctly) should help shape the project into something that is compatible with both organizational goals and organizational constraints.  The gate system, the variation I’m most familiar with, provides a way of checking that the project is tracking correctly as it proceeds from concept to preliminary design to final design and to implementation.  If the budget proves unrealistic or the goals prove unattainable, management has several opportunities to reconfigure or terminate the project before more resources (often far greater resources) are devoted to it.

As for cybernetic controls, meaningful progress reporting and feedback about current and foreseeable problems are all elements that allow a reasonably aware PM to “keep his eye on the ball” and control the project. (I hate clichés, but that one fits.) 

Postcontrol, as noted by the text, is an after-the-fact process that focuses on making future projects better, so that the team actually learns something from what went right and what went wrong.  You don’t need this process to make a current project successful, but you could have made that project even more successful had you the benefit of “organizational process assets” (a PMIism) that provided you insight before you started.  That’s why postcontrol is important, and I predict it will become, in time, accepted by all successful companies.  (We’re not there yet but things are changing.)

• Comment:  It is unclear which automated project management tools fall under the category of cybernetic controls. The book describes systems used to replace human actions, excepting the third-order type. However, in the module, it is suggested that overcompensating for an input by getting two more D-9s instead of one is cybernetic.   

Instructor’s reply:  See previous comment just above regarding why we shouldn’t regard cybernetics as exclusively automatic by nature.  Your point about overcompensation is a valid one, and it’s a system stability issue.  With automatic controllers, they can be tuned using their programmed tuning parameters.  Unfortunately, people are not automatic controllers, and are prone to overreact if they act at all.  But they are responding to feedback, and so it is cybernetic in character.

• Comment:  I don’t see anywhere in here where we use Microsoft Project software. Is there a way you can just keep using the same program and let the PM do the data entry in his choice of form. I don’t even see use of software through the rest of the book.

Instructor’s reply:  You’re right, the rest of the book doesn’t use it.  Meredith and Mantel, and other reputable authors, understand that Project Management is a lot more than manipulation of software like Microsoft Project.  Not everyone in industry and government recognizes this, unfortunately.  However, with the PMP certification movement spreading like wildfire, the bar is being raised at last.

• Comment:  Didn’t like the post control topic.  But that’s because I had trouble placing it under “control”.  Does the PM handle this?  More of a company or organizational thing.

Instructor’s reply:   The PM certainly needs to be part of the postcontrol process, but my view is that this is something best spearheaded by someone else, someone who can be impartial.  The PM is too close to the project to be objective.  The stakeholders in particular need to be heavily involved in postcontrol as well.  They don’t necessarily know about the problems in execution faced by the PM, but they are in a better position to judge the overall product quality resulting from the project.  So, I agree with you – postcontrol is a process that needs organizational support.